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About this document 


This document describes the Remote Data Polling System (XFER) facility 
and XFER menu commands provided in the NTX059AB feature package. 
Also discussed is the Network Operating System (NOS) facility and the 
Network Operation Protocol (NOP). NOP is provided in the NTX560AB 
feature package. 


Applicability of this document 
Northern Telecom (NT) software releases are referred to as batch change 
supplements (BCS) and are identified by a number, for example, BCS29. 


This document applies to DMS-100 Family offices that have BCS33. 
Unless the document is revised, it also applies to offices that have software 
releases greater than BCS33. 


More than one version of this document may exist. To determine which 
version applies to the BCS in your office, check the release information in 
Guide to Northern Telecom Publications, 297-1001-001. 


How to identify the software in your office 
Software applicable to a specific DMS-100 Family office is identified by a 
BCS release number and by NT Product Engineering Codes (PEC). The 
significance of the BCS number and the PEC is described in Provisioning, 
297-1001-450 (section 450/32) and in the Office Feature Record D-190. 


The Office feature record D190 lists your current BCS and the NT feature 
packages that it comprises. To view similar information on screen, enter the 
following command string at a MAP (maintenance and administration 
position) terminal. 


PATCHER;INFORM LISTLEAVE 
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How the Remote Data Pooling System (XFER) documentation 
package is organized 
This document is part of the XFER documentation package that supports 


NTs line of XFER products. The XFER documentation package is a subset 
of the DMS-100 Family library. 


Where to find information 
Documents that you require to understand the content of this document are 
listed below. These documents are also referred to in the appropriate places 
in the text. 


Note: More than one version of these documents may exist. To 
determine which version of a document applies to the BCS in your 
office, check the release information in Guide to Northern Telecom 
Publications, 297-1001-001. 


Prerequisite References 


| Document Title | 


| 297-1001-100 Dms-100 System Description | 


| 297-1001-312 Device Independent Recording Package (DIRP) User Guide | 


297-1001-525 Data Packet Controller Reference Manual 


Informative References 


Document Title 


297-1001-001 Guide to Norfthern Telecom Publications 

297-1001-110 Maintenance and Administration Position (MAP) 
297-1001-119 | Automatic Message Accounting--Northern T elecom Format 
297-1001-160 | Automatic Message Accounting Bellcore Format User Guide 
297-1001-310 Table Editor Reference Manual 

297-1001-312 Device Independent Recording Package User Guide 
297-1001-450 Provisioning 

297-1001-451 Common Customer Data Schema 


297-1001-500 Index to Maintenance Procedures Documents 
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Document Title 


297-1001-513 Input/Output Devices (IOD) Man-Machine Interface 
Description 


297-1001-517 External (EXT) Alarms Man-Machine Interface Description 
297-1001-520 Maintenance System Man-Machine Interface Description 


297-1001-830 Automatic Message Accounting Bellcore Format Reference | 
Manual 


450-1021-311 DNC-100/DNC-500 Dynamic Network Control Systems: 
BNM Input/Output Procedures 


NT and Bell-Northern Research (BNR) trademarks and the products 
they represent 


The following chart lists all NT and BNR trademarks that occur in this 
document, and associates them with the products they represent. 


Trademark Product 

DMS Digital multiplex system 
telephone switching equipment 

DMS SuperNode telecommunications switching equipment 

NT Northern Telecom 
a company that produces telecommunications switching 
equipment 

MAP Maintenance and administration position 


telephone communication equipment 


What precautionary messages indicate 
In this document, caution, danger and warning messages indicate potential 
risks, as identified in the following chart. 


Message Significance 


CAUTION Possibility of service interruption or degradation 
DANGER Possibility of personal injury 
WARNING Possibility of equipment damage 


Examples of the precautionary messages follow. 
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CAUTION 

Calls are dropped when line group controller is busied. 
Manually removing the line group controller from 
service removes all its subtending peripheral modules 
from service. All calls in progress are dropped. 


DANGER 

Risk of electrocution 

The inverter contains high voltage lines. Do not open 
the front panel of the inverter unless fuses F1, F2, and 
F3 have been removed first. Until these fuses are 
removed, the high voltage lines inside the inverter are 
active, and you risk being electrocuted. 


WARNING 

Backplane connector pins may become damaged. 

Use light thumb pressure to align the card with the 
connectors. Next use the levers to seat the card into the 
connectors. Failure to align the card first may result in 
bending of backplane connector pins. 


How commands, parameters, and responses are represented 
In this document, commands, parameters, and responses are represented 
according to the following conventions. 


Input prompt (>) 
An input prompt (>) indicates that the information that follows is a 


command. 


Type the command that follows the input prompt and press the carriage 
return key. 


Capital letters 
Capital letters represent commands, fixed parameters, and responses that 
appear at a MAP. 


Enter the command or fixed parameter exactly as it appears on the page. 
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Lowercase letters 
Lowercase letters represent variables. 


For commands and parameters, enter the letters or numbers that the variable 
represents. In most instances, the name that is used for the variable 
indicates clearly what you must enter. Where it does not, further 
explanations are provided. 


In responses (which are presented in capital letters), lowercase letters 
represent a range of values. 


Brackets [ Jor [ ] 


Brackets enclose optional parameters. A vertical list enclosed in brackets 
means that one or more of the parameters may be selected. 


Underscore connecting words 
Underscore connecting words means the words are to be treated as one item, 
for example, pm_type or #_one_two. 


Indicates repeated steps or items. 

In addition, the following conventions are used. 

n (lowercase n) is a number from 0 to 9. 

a (lowercase a) is a letter from A to Z. 

h (lowercase h) is a hexadecimal integer from 0 to F. 


The following example illustrates the command syntax that is used in this 
document. 
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Step 


1 


input> 


parameters> 


Example 
input> 


Example 
output> 


Examples of command syntax used in this document 


Action 


Post the card in the inactive unit. 
>POST unit_no card_no state 


where 

unit no is the number of the inactive unit (0 or 1) 

card_no is the number of the card you replaced (22-27) 

state is the state of the unit in which you wish to 
replace the card (Insv, SysB, ManB or Offl) 


For example: 
>POST 7 1 INSV 


CARD 7 IS POSTED IN UNIT 1 OF MSB16 
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Remote data polling system operation 


The Remote Data Polling System (XFER) permits an Operating Company to 
transfer information such as Automatic Message Accounting (AMA) data or 
Operational Measurements (OM) data to its data processing center. 


Such data is stored on a variety of recording devices at the DMS office, by 
means of the device independent recording package (DIRP), explained more 
fully in Device Independent Recording Package User Guide, 

297-1001-312. Data is made available, through DIRP , to the XFER for 
transmission to the data center. 


Note: For information on data transferal as it applies to Network 
Operation System (NOS), refer to Chapter 5 on page 5-1. 


Configuration 
Data transferal is done via a digital data packet switching network, such as 
DATAPAC (see Data Packet Controller Reference Manual, 297-1001-525), 
as shown in Figure 1-1 on page 1-3. 


As shown in the figure, a standard network dataset interface in the data 
center office is connected through a pair of line controllers to the data center 
computer. A visual display unit (VDU) is connected to the computer via a 
terminal controller. 


At the DMS office a network dataset interface is connected via an Electronic 
Industries Association (EIA) RS-232-C interface cable to a data packet 
controller (DPC) circuit pack (1X67BB or 1X67BD). 


The DPC implements the network framing pattern, handles the cyclical 
redundancy check (CRC), and interfaces with the input/output controller 
(IOC). 


The multi-protocol controller (MPC) is a hardware circuit card (1X89) 
based on the 68000 microprocessor. The MPC resides between the IOC bus 
on the central control (CC) side of the IOC shelf and and two RS-232-C 
communication links to other systems on the other side. 
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The MPC performs the same functions as the DPC more quickly, saving 
central processing unit (CPU) real time in standard call processing. 


Other Input/Output devices (IOD) are connected to the IOC using 
appropriate device controller circuit packs. The MAP connects to a terminal 
controller circuit pack (1X67AB). 


Optional feature package NTXJ44AA supports the DIRP to record 
subsystem data on another device in DMS-Supernode called system load 
module (SLM). The SLM file system supports the functionality of the IOC 
disk file system on the DMS-Supernode. On a per disk basis, the SLM disk 
has shorter access time and larger storage capacity than the standard IOC 
disk. Because SLM tape files are not supported, only SLM disk files can be 
transmitted to Revenue Accounting Offices (RAOs) by using XFER utility. 
See Device Independent Recording Package User Guide, 297-1001-312, for 
more information on SLM disks. 


297-1001-524 Standard 09.01 October 1991 


Remote data polling system operation 1-3 


Figure 1-1xxx 
Remote data polling system hardware configuration 
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Figure 1-2 


The XFER software controlling the XFER is resident in the DMS switch and 
is responsible for the following functions: 


e handling incoming requests for data 
e presentation of inventory lists of available data to the data center 
e coordinating data transferal sessions. 


Figure 1-2 illustrates the relationship between the DIRP and the XFER 
system. 


Interrelationships in data management 
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Procedural overview 


Transmission of recorded data to a remote Operating Company data center is 
accomplished by means of the DIRP and the XFER level of the MAP and 
generally involves the following step. 


1 The remote data center contacts the DMS office via the packet switching 
network. 


2 The network address of the calling data center is verified by comparing 
it to the list of authorized users in Data Table XFERADDR. 
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Once the incoming request is verified, the DIRP makes the latest 
recorded data available. 


The data center scans the contents of the DIRPHOLD table, and selects a 
file for transmission. 

DIRP manipulates the appropriate recording device and the file is 
transmitted. 


On completion of transmission, the data center sends instructions for 
final disposition of the file. 


Transferal protocols 
There are two basic methods of data transferal, Automatic and Manual. 


Automatic transferal 

Normally, the DIRP manipulates the files under its control in order to meet 
the recording needs of the switch. In turn, file identification information is 
recorded in the DIRPHOLD control table, creating an inventory of data files 
that are available for transmission. Files originating in this fashion are 
labeled as being in the unprocessed (UNPROC) state (see Table 3-1 on page 
3-7). 


DIRP then proceeds as follows in processing the files and initiating 
automatic transferal. 


1 


When the remote data center establishes contact with the DMS office, 
DIRP is instructed to perform a ROTATE and CLOSE procedure. DIRP 
attempts to rotate the recording duties of the files assigned to the 
particular subsystem being polled. DIRP then closes any files that can 
be closed, while preserving the minimum number of files specified for 
the subsystem. See Device Independent Recording Package User Guide, 
297-1001-312, for more information on DIRP procedures. 


The closed files are identified in Table DIRPHOLD, ensuring that the 
latest recorded data is available to the data center. The data center 
selects the file it wants to receive from the contents of DIRPHOLD and 
requests the desired file from the DIRP, using the XFER MAP level. 


DIRP controls the necessary recording device, and XFER transmits the 
requested file to the data center. 


Following transmission, the data center sends instructions concerning the 
file to XFER, which in turn instructs the DIRP concerning file 
disposition. 

If the data was correctly received, the DIRP is instructed to retain the file 
for reuse. If a file is retained for reuse, its state is changed to AGEING 
(see Table 3-1 on page 3-7). 
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6 Inthe event that the data center detected errors during the transmission, 
the original file is required for verification and a request to transport the 
file to the data center is sent to XFER. The file status is changed to 
TOSEND, and a SENDnn minor alarm is raised (see Table 1-1 on page 
1-6and Table 3-1 on page 3-7). 

7 Ifno specific instructions are received, it is assumed that the data was 
not successfully received by the data center. The file state is not 
changed from UNPROC, and the file is available for further attempts at 
transferal. 


Table 1-1xxx 
Data transferal alarm indications 


| Indication Meaning | 
XMITnn The data center has requested that a file, identified at the 


position indicated by the key field value ‘nn’ in Table 
DIRPHOLD, is to be transmitted. 


DMNTnn Transmission of a tape volume has been completed and 
Operating Company personnel should remove the tape 
from the MTD. The volume is identified by its key field 
value ‘nn’ in Table DIRPHOLD. 


SENDnn The file identified by key field value ‘nn’ in Table 
DIRPHOLD cannot be received by the data center or 
Telco Network Operations System (TNOS). Physical 
intervention by Operating Company personnel is 
necessary. 


KEEPnn The file identified by key field value ‘nn’ in Table 
DIRPHOLD has been successfully transmitted to the Data 
Center or TNOS, and the file space can be reused by the 
DMS office, after expiration. 


Page 1 of 1 


Manual 

Files that are not under the DIRP control may be manually transferred to a 
data center. Any file can be added by Operating Company personnel to the 
DIRPHOLD table to make it available for transmission to the data center. 


For example, if a recording volume is part of a pool of devices (in Table 
DIRPPOOL) that is no longer used by the originating subsystem, all files on 
the volume are removed from the DIRP control and are placed under manual 
control. Such files can still be made available for transferal by manually 
creating entries for them in Table DIRPHOLD. 
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If the data center requests a file that is not under the DIRP control, operating 
company personnel are alerted by alarms. 


Transmission of files under manual control is conducted using the 
commands of the XFER level of the MAP. These commands are described 
in Chapter 3 on page 3-1. 


Files being transmitted are monitored by four minor alarms. These alarms 
appear under the IOD heading of the top level maintenance subsystem 
header and are described in Table 1-1 on page 1-6. 


A sample data transferal session using XFER is presented in Chapter 4 on 
page 4-1. 
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Data assignment 


This part of the document defines the data tables that need to be datafilled in 
order to activate the remote data polling system (XFER) facility. The 
activation of the XFER facility is accomplished by datafilling the tables 
listed in Table 2-1 below. 


Table 2-1xxx 
Data tables for activation of NTX059AB 
Table Section Form Table title 
| DPACDEV 008 2058 DATAPAC Device | 
GDLADEV 096 2063 Device Definition 


XFERADDR 045 none Data Transferal Address Information 
XFERSSYS 00A 2362 Data Transferal Subsystem 
Page 1 of 1 


Refer to Common Customer Data Schema, 297-1001-451, for more 
information about any of these tables. 


Table DPACDEV 
Table DPACDEV must be datafilled to implement one or more data pocket 
collector (DPC) circuit packs in the DMS Input/Output subsystem. See 
Data Packet Controller Reference Manual, 297-1001-525, for more 
information about the Data Packet Collector. 


Table GDLADEV 
Table GDLADEYV is used in combination with Table XFERADDR and must 
be datafilled before Table XFERADDR. Refer to Table 2-2 on page 2-2 
for a definition of the fields in this table. 


Table GDLADEYV contains four tuples, one for XFER and three for future 
expansion. Only one device can be associated with a given application in 
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this table at a time. For instance, attempts to associate XFER with both the 
multi-protocol controller (MPC) and the DPC are not allowed. 


Table 2-2xxx 
Table GDLADEV field descriptions 


| Field name Entry Explanation | 


APPLN XFER or NOP APPLICATION NAME. This field identifies 
the data transfer application to be used with 
an associated device as defined in the 
DEVICE field. There is no default. 


DEVICE MPC or DPC TRANSMISSION DEVICE NAME. This 
field defines the transmission device to be 
associated with a specific data transfer 
application, as specified in the APPLN field. 
There is no default. 
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Note: 1 Datafilling Table GDLADEYV is not required in offices with 
transmission applications other than XFER. If XFER is used, Table 
GDLADEV must be datafilled as in the following example: 


TABLE: GDLADEV 
TOP 


APPLN DEVICE 


XFER MPC 


BOTTOM 


In this example, XFER is the transfer application and MPC is 
chosen as the transmission device. 


Note: 2 To change which transmission device XFER uses (for example, 
from DPC to MPC), all tuples in the XFERADDR table must be deleted 
before Table GDLADEV can be changed. 


Table XFERADDR 
The fields for Table XFERADDR are defined in Table 2-3 on page 2-3. 
DPC identifiers in this table correspond to those in Table DPACDEV. 


Table XFERADDR can contain a maximum of 64 tuples, one for each 
possible virtual network connection that can be established by the office. 
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More than one of these connections can be in use simultaneously to handle 
multiple polling requests. Entries represent possible virtual connections 
only, and more than one entry may map to the same DPC circuit pack. 


Table XFERADDR requires approximately 192 words of dynamic data store 
for 64 tuples. Table GDLADEV requires eight words of dynamic storage 
for four tuples. 


Table 2-3xxx 

Table XFERADDR field descriptions 

Field name Entry Explanation 

INDEX 0 through 63 TABLE INDEX. Enter an integer from 1 to 

63 as an index for Table XFERADDR. 

ADDRESS 00000000 NETWORK ADDRESS. Enter the network 
through address number entered in the NODENUM 
99999999 field of Table DPACDEV. 

UNIT -32768 MPC or DPC UNIT NUMBER. Enter the 
through MPC or DPC number. If only the DPC is 
32767 resident to the switch, only the DPC unit 


number will be entered. If only the MPC is 
resident to the switch, only the MPC unit 
number is entered. The unit numbers are 
obtained from Table MPC or Table 
DPACNUM. Common Customer Data 
Schema, 297-1001-451, section 078, 
describes Table MPC. Common Customer 
Data Schema, 297-1001-451, section 008, 
describes Table DPACNUM. If the MPC is 
datafilled in Table GDLADEV, values for this 
field are limited to O through 255. If the 
DPC is datafilled in Table GDLADEV, values 
for this field are limited to 0 through 15. 
There is no default. 


LINK -32768 MPC LINK NUMBER. The only values that 
through can be entered for the MPC are 2 and 3. If 
32767 the DPC is datafilled in Table GDLADEV, 


the value for the MPC LINK field must be 
-1. There is no default. 
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Table XFERSSYS 


Table XFERSSYS holds the information that was previously provided in the 
DEFINE command at the XFER level of the MAP (maintenance and 


administration position). This table stores information about each device 
independent recording package (DIRP) subsystem whose data can be 
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transmitted using XFER. The fields for Table XFERSSYS are defined in 
Table 2-4 on page 2-4. 


Table XFERSSYS contains 24 tuples and requires 72 words of data store. 
subsystem must be datafilled in Table DIRPSSYS prior to datafilling the 
subsystem in Table XFERSSYS. 


Table 2-4xxx 
Table XFERSSYS field descriptions 


Field name Entry Explanation 


SSNAME 1 through 4 SUBSYSTEM NAME. Enter the name used 
character to identify the subsystem to DIRP. The 
string subsystem must be known to DIFP prior to 

using it in this field. 


PROTCLID 1 through 255 PROTOCOL IDENTIFICATION NUMBER. 
Enter the transferal protocol identification 
number by which the subsystem is known to 
data center. This number is supplied by the 
pooler and must be converted from hex to 
decimal. 


FUNCTION KEY. Enter the key (menu item 
number) by which the subsystem is to be 
known at the XFER level of the MAP. Keys 
2 through 12 are predefined for XFER 
commands and cannot be used for 
subsystems. Keys 13 through 18 can be 
defined for subsystems by using this table. 
The entry for the defined subsystem will not 
appear in the menu until the user exits and 
re-enters the XFER level of the MAP. 
FNONE means that no function key is 
specified for this subsystem and it will not 
appear on the menu. 
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XFER menu and commands 


XFER menu 


The remote data polling system (XFER) level of the maintenance and 
administration position (MAP) is accessed from the Input/Output device 
(LOD) level with the command ‘XFER.” The IOD level MAP display is 
illustrated in Figure 3-1 on page 3-1, while the XFER level display is 
illustrated in Figure 3-2 on page 3-2. 


Figure 3-1xxx 
IOD subsystem status and menu display 
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The division of the MAP screen into various application areas is described 
in Maintenance System Man-Machine Interface Description, 
297-1001-520. 


The labels device independent recording package (DIRP) and XFER appear 
on line 7 of the display. Next to each of these, any alarm conditions 
applicable to these subsystems are displayed. DIRP alarm indications are 
described in Device Independent Recording Package User Guide, 
297-1001-312. XFER alarm indications are described in Table 1-1 on page 
1-6. If there are no alarm conditions, a dot (.) appears. 


Of the items appearing on the XFER menu, those numbers 3 through 9 and 
12 are commands. Items 10 and 11 are parameters used with some of the 
commands. Parameters appear on the menu for convenience of input. 


Figure 3-2xxx 
XFER level menu display 
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Commands and parameters can be entered at the MAP in either of two ways. 


e The item itself can be entered, character by character, regardless of 
uppercase and lowercase form. 
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e The number associated with the menu item can be entered instead of the 
item. 


Presentation of commands 
In this section, commands are described in alphabetical order and in a 
standard format. 


The syntax of the commands is given using the following conventions. 


e The command name is given in the left part of the figure and the 
associated parameters are given in the right part. 


e Optional parameters are shown between square brackets, [ ]. 


e Required parameters are shown separately, with no brackets, and are 
stacked vertically if a selection may be made. 


e Characters required to be typed in are shown in UPPERCASE, and 
named parameters, described in the text following the figure, are shown 
in lowercase. 


See How Commands, Parameters, and Responses are Represented on page 
viii for more information on notational conventions used in this section. 


The “command syntax box” for each command is followed by a description 
of the process that the command initiates. System responses and usage 
notes are also described. 


The following commands, presented in alphabetical order, are supported at 
the XFER level of the MAP. 


| ABORTX | index 


ABORTX is used to indicate that the file requested by the data center cannot 
be transmitted. 


Where: 
index is the key field index number for the requested file, from the Table 


DIRPHOLD. 


Note: 1 The system cancels the XMITnn minor alarm that was raised in 
response to the data center or TNOS request and sends a message 
indicating that the file will not be transmitted. 


Note: 2 The data center or TNOS can request that another attempt be 
made to transmit the file. 
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DEFINE subsystem protocol_id mode menu_number 


DEFINE previously controlled an interface function between DIRP, XFER, 
and the data center requesting data transmission. The functions of this 
command have been replaced by Table XFERSSYS. Use of the DEFINE 
command results in the following response. 


PLEASE USE TABLE XFERSSYS TO DEFINE A SUBSYSTEM FOR XFER 
TO UNDEFINE A SUBSYSTEM, DELETE THE TUPLE FOR THAT SUBSYSTEM 


Refer to Chapter 2 on page 2-1 and Common Customer Data Schema, 
297-1001-451, for information on Table XFERSSYS. 


ae 


DMNT indicates to the XFER that the tape which contains the specified file 
has been demounted from its drive, as requested. 


Where: 
index is the key field index number from the Table DIRPHOLD, for the 
file contained on the tape that has been demounted. 


Note: The command has the effect of cancelling the DMNTnn minor 
alarm that is raised when the DEMOUNT TAPE instruction is received. 


KEPT index 


KEPT indicates to the system that the specified file has been retained for 
reuse in the office, as requested by TNOS or the data center. 


Where: 
index is the key field index number of the file that has been retained, from 
the Table DIRPHOLD. 


Note: I This command only applies to files under manual control, since 
files under automatic control are stored by the system and later reused. 


Note: 2 The command causes the system to cancel the KEEPnn minor 
alarm that was raised when the instruction to retain the file was received 
from TNOS or the data center. 
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subsystem 
index 


QUERY causes the display of relevant transferal information concerning the 
specified group of files. 


Where: 

XMIT specifies the group of files that have been requested for 
transmission. 

SENT specifies the group of files that are to be transported physically 
to the data center for verification purposes. 

KEPT specifies the group of files, under manual control, which are to 
be retained at the DMS office for eventual reuse. 

DMNT specifies the group of files, contained on tapes, that need to be 
demounted from their drives. 

SSYS specifies all files originating from the subsystem indicated by 


the next parameter. 


subsystem is the name of the originating subsystem. 


HOLD followed by an index number, specifies one particular file 
listed in the DIRPHOLD control table. 


index is the key field index number, from Table DIRPHOLD, for the 
file for which information is to be displayed. 


Note: This command causes information to be displayed at the MAP, as 
illustrated in Figure 3-3 on page 3-7. The menu area of the MAP 

screen has been omitted for clarity. Information appears under the 
following headings: 


HOLDNO is the key field index number of the tuple concerning a file in 
Table DIRPHOLD. 
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STATE 


SSYS 


ORIG 


DMNT 


FILENAME 


COUNT 


is the Transferal State Code currently assigned to the file, as 
described in Table 3-1 on page 3-7. 


is the name of the originating subsystem. 


indicates whether the file was made available due to manual or 
system action, entry is either MAN or DIRP, respectively. 


is for files contained on magnetic tape and indicates whether 
the tape has been demounted after transmission, entry is either 
YES or NO. 


is the name of the file; file types such as tape and tapex, use 

the file name assigned in the datafill of Table DIRPSSYS; if 
none is assigned there, the name defaults to a name generated 
by the system. With files that are type disk, the name is always 
generated by the system. 


is the number of records in the file. 


FILE_LOCN is the name of the volume containing this file. 


Note: If the group of files was specified by subsystem, the current 
definition of the subsystem to the XFER system is also displayed. 
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XFER response to QUERY command 


OLDNO STATE SSYS ORIG DMNT FILENAME COUNT FILE_LOC 


61TOXMIT AMA MAN 


62DTLOCK AMA DIRP 
63UNPROC OM MAN 


OPERATOR 
TIME 15:06 >_ 


NOA820226031105AMA 17238 7464584 
NOA820225031106AMA 16633 9000 000 
NO A8202141502070M 9836 372583 


Table 3-1xxx 


File states for data transferal system 


Code Meaning 


Explanation 


NOFILE no file 


There is no file currently listed at that 
location in DIRPHOLD. 


UNPROC unprocessed 


This file has not yet been successfully 
transmitted to the data center. 


DTLOCK data transferal 
locked 


This file is currently under the control of 
the data transferal system. No manual 
action is allowed on this file unless the 
data transferal session is first interrupted 
or terminated. 


TOXMIT to be transmitted 


A request has been received from the 
data center to transmit this file. 


Page 1 of 2 
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Table 3-1xxx 

File states for data transferal system (continued) 

Code Meaning Explanation 

TOSEND to be sent The data center has requested that this 
file be transported to the center for 
verification. 

TOKEEP tobe kept The file has been processed and should 


be retained by the office for reuse. This 
applies only to files under manual 
control. 


held, awaiting its expiration date. This 


RELOAD verifying over A reload/restart has occurred and the 
reload system is in the process of verifying the 
contents of this file. This applies only to 
disk-type files. 


AGEING aging The file has been processed and is being 


applies only to files under system control. 


Page 2 of 2 


REVIVE XFERCALL 
XFERCLR 
ALL 


REVIVE brings back into activity a failed XFER process without a DMS 
restart. 


Where: 
XFERCALL specifies that the call-waiting process is to be revived. 


XFERCLR specifies that the call-clearing process is to be revived. 
ALL specifies both processes are to be revived. 


Note: If it is necessary to manually REVIVE an XFERCALL or 
XFERCLR process, a software error may be indicated and should be 
explored before attempting to REVIVE the system. Recurring faults 
reflected in system logs should aid in determining the source of 
problems. 


Responses: 
PROCESS xxxx REVIVED 
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Explanation: The process has successfully been brought back into activity. 
Expression xxxx specifies the process requested for revival. 


PROCESS xxxx ALREADY RUNNING 


Explanation: A process xxxx requested for revival is still active and does 
not need to be revived. 


UNABLE TO REVIVE PROCESS xxxx 


Explanation: XFER cannot revive the process xxxx due to software error. 
No response 


Explanation: REVIVE was attempted with ALL parameter when specified 
processes were already running. 


UNABLE TO COMPLETE REVIVE ATTEMPT 


Explanation: Software difficulties have prevented the REVIVE procedure 
from being attempted. 


WAIT ON REPLY TIMED OUT 
ATTEMPT TO ABORT REVIVE IS BEING MADE 


Explanation: A mailbox timeout (error) has occurred. 
System Action: The system tries to stop the REVIVE. 


User Action: To determine whether or not the processes are stopped or 
running, enter QUERY PROCESS XFERCALL or QUERY PROCESS 
XFERCLR at the MAPCTI level. Contact the next level of maintenance. 


Any of the following responses: 


MAILBOX RESET FAILED WITH RETURN CODE nn 


MESSAGING ERROR; MBRC IS nn 


MAILBOX ALLOCATION FAILED WITH RETURN CODE nn 


MAILBOX DEALLOCATION FAILED WITH RETURN CODE nn 


Explanation: Software Operating System (SOS) errors have interfered with 
messaging. 


System Action: The REVIVE process is aborted. 
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User Action: Note the return code nn. Contact the next level of 
maintenance. 


SENT index 


SENT indicates to the system that the specified file has been physically sent 
to the data center or TNOS as requested. 


Where: 
index the key field index number, from the Table DIRPHOLD, for the file 
that was sent. 


Note: The command has the effect of cancelling the SENDnn minor 
alarm that is raised when the data center or TNOS requests that the file 
be sent out. 


XMIT index 


XMIT initiates the transmission to the requesting TNOS or data center of a 
specified file. The file is identified by reference to its key field index 
number in the Table DIRPHOLD. 


Where: 
index is the key field index number for the file to be transmitted, from the 
Table DIRPHOLD. 
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Manual transferal protocol sequence 
If the file requested by the polling data center is under manual control, the 
manual transferal protocol is initiated. Under this protocol, when the 
request for transmission of a file is received by the DMS office, an XMITnn 
alarm is raised, indicating the DIRPHOLD key field index number of the 
requested file. 


In response, operating company personnel input the command QUERY 
HOLD nn, where nn is the key field index number identified in the XMIT 
alarm. Once the file is identified, it is prepared for transmission, on the 
appropriate recording device. 


Since the file is under manual control, it is necessary to ensure that DMS 
internal software is aware of its presence. This is accomplished by the 
process of listing the volume. 


For example, if the file is contained on a tape, and the tape has been 
properly placed on magnetic tape drive (MTD) 2, the following commands 
are used at the maintenance and administration position (MAP) to list the 


volume: 
> MOUNT 2 to mount the tape on the drive 
> LIST T2 to instruct the system to read all the file names 


on the tape. 


In the case of a file contained on, for example, disk volume DOOOVOL3, the 
sequence of commands is: 


> DSKUT to access the Disk Utility software. 


> LISTVOL DOOOVOL3 ALL to instruct the system to read all the file names 
on that volume 
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> QUIT to leave Disk Utility. 


Once the process of listing the volume has been completed, the command 
XMITnn is input to initiate transmission of the file. 


Following transmission, the data center usually sends instructions 
concerning the file to the DMS office. If the data was received correctly, the 
instruction causes a KEEPnn alarm to be raised. This indicates that the file 
space can be reused in the DMS office, once the expiration date of the file 
has been reached. The KEPTnn command acknowledges the instruction and 
cancels the alarm. If the data center detected errors during transmission, or 
is conducting a routine periodic audit, the instruction specifies that the 
original file should be transported to the data center. A SENDnn alarm is 
raised. After arranging for the file to be transported, the alarm is canceled 
using the SENTnn command. 


Also after transmission, in the case of a file contained on a tape, the DMS 
office raises a DMNTnn minor alarm indication. This indication may be 
temporarily masked by the alarms raised in response to the disposition 
instructions from the data center. If masked, the DMNT indication becomes 
apparent when attempting to cancel the SENDnn or KEEPnn alarm. 


In response to the DMNT minor alarm, operating company personnel 
remove the required tape from its drive and use the DMNTnn command to 
cancel the alarm. This completes the procedure. 
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Network operating system (NOS) 
communications 


This part of the Practice describes Network Operating System (NOS) 
communications. NOS communications is handled by the Network 
Operation Protocol (NOP). 


What is the network operation protocol (NOP)? 
The NOP is the protocol by which a DMS communicates with NOS 
products. The NOP uses the Remote Operation (RO) Service to handle the 
communications between the DMS applications and the remote systems by 
using an RO. An RO is a task requested by one processor but performed by 
another processor. Refer to What is the Remote Operation (RO) Service? on 
page 5-6 for more information about the RO Service. 


The NOP uses the International Standards Organization (ISO) seven layer 
architecture. Layers 1, 2, and 3 use the DATAPAC version of X.25. Layers 
4 and 5 are null layers, that is, they are not used and perform no function. A 
subset of layers 6 and 7 make up the RO Service. 


Refer to Figure 5-1 on page 5-3 for an illustration of the layers and their 
relationships. 


What are the network operating system (NOS) products? 
An NOS product is any of a series of products that are used to offload data 
processing at the DMS. For example, an NOS product can be one of the 
following products: 


e Business Network Management (BNM) 


BNM is aproduct that is an application of Northern Telecom’s (NTs) 
Dynamic Network Control (DNC) products that gives customers direct 
access to call detail, station administration, and performance information 
from one or more Meridian Digital Centrex (MDC) nodes in their 
telecommunications network. 


e Station Detail Server (SDS) 
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The DNC-50 SDS is a member of the DNC-500 BNM family. The SDS 
provides Station Message Detail Recording (SMDR) from a DMS-100 
to an end-user’s premises. 


e Large Business Remotes (LBR) 


LBR is a product that is basically a DMS-100 switch configured to serve 
as a remote switching center. An LBR is connected to a centralized 
operations, administration and maintenance (COAM) device. A COAM 
is an application on a DNC-500 providing centralized operations, 
administration, and maintenance for DMS-100 family products. 


e Dynamically Controlled Routing (DCR) 


DCR is a product that provides improved routing control of calls 
overflowing the direct routes within a network of switching centers. It 
does this by evaluating congestion within the network and 
recommending the most idle alternate routes to each participating 
switch, on a 10-second cycle. 
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Figure 5-1xxx 
NOP in the ISO seven layer architecture 
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When is the network operation protocol (NOP) used? 
An NOS processor requests that tasks be performed by a DMS by sending 
RO requests using NOP to the DMS. NOS products have a set of ROs that 
are used to request tasks to be performed by the DMS. The DMS has ROs 
that it uses to respond to the DNC ROs. 
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The NOP is used when transmitting the data related to the following 
applications to and from a DMS. 


File Transfer (FT): This application provides the DMS with the 
capability to transfer operating company and customer data stored in the 
device independent recording package (DIRP) subsystems over a 
communication link. The following types of data streams can currently 
be transmitted: 


- Automatic Message Accounting (AMA) 

- Automatic Trunk Testing Facility (A TTF) 
- Killer Trunk (KT) 

- Operational Measurements (OM) 

- Station Message Detail Recording (SMDR). 


Refer to File Transfer (FT) Remote Operation (RO) on page 5-9 for an 
explanation of the four FT ROs. Refer to DNC-100/DNC-500 Dynamic 
Network Control Systems: BNM Input/Output Procedures, 
450-1021-311 for more information about collecting operating company 
and customer data. 


Transactions (TRAN): The TRAN application sends supervisory 
information. Refer to Transaction (TRAN) Remote Operation (RO) on 
page 5-9for an explanation of the four TRAN ROs. 


Passthru Application Entity (PTAE): Also known as Centralized MAP 
(CMAP), this application allows NOS users access to the DMS MAP 
from a remote system. This application was known as Pass Through 
DMS Access (PTDA) and MAP. Refer to Passthru Application Entity 
(PTAE) Remote Operation (RO) on page 5-10 for an explanation of the 
nine PTAE ROs. 


Centralized Alarms (CALM): The CALM application sends alarms 
from a DMS to an NOS product user at a terminal. There can be a 
maximum of two CALM sessions at one time, that is, two DNCs can be 
collecting alarms from the same DMS. However, only one CALM 
session can be sent at one given time to a particular NOS product. Refer 
to Centralized Alarms (CALM) Remote Operation (RO) on page 5-10 
for an explanation of the two CALM ROs. 


Dynamically Controlled Routing (DCR): The DCR application sends 
data regarding routing control of calls. There are nine DCR ROs, but 
they are not displayed at the NOP MAP level. 


The DIRP subsystems use NOP to send data to and communicate with an 
NOS product. Refer to Figure 5-2 on page 5-5 for an illustration of the 
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interrelationship between the DIRP subsystems using NOP and an NOS 
product. 


Figure 5-2xxx 
DIRP interrelationships using NOP to NOS 
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What is a network operation protocol (NOP) session? 
When data is passed between a DMS and an NOS product using NOP, it is 
passed using a switched virtual circuit (SVC). The sending of data using an 
SVC is called a session. The NOP MAP level is used to monitor 
communication between a DMS and an NOS product by keeping track of 
the sessions between a DMS and an NOS product. 


A session between a DMS and an NOS product can have five states. The 
five states are actually the states of the SVC through which the data is sent. 
The following are the five session states: 


1 IDLE: No session (SVC) has been established. The UP and DOWN 
tasks within the RO Service are waiting for a call between the DMS and 
a nNOS product to arrive. 

2 LOGGED OFF or UNASSIGNED: A session (SVC) has been 
connected. The RO Service is waiting to receive a logon RO. 

3 LOGON PENDING: A logon RO has been received by the RO Service 
from the application and is being processed. The proper application’s 
task is initialized and storage allocations are made. 

4 LOGGED ON or ACTIVE: The logon has been verified. The 
application’s task is running. 

5 LOGOUT PENDING: A logoff RO has been received by the RO 
Service from the application and is being processed. The application’s 
task is deallocated and memory is cleaned up. 


The number of sessions is set by the NOS_QUANTITY_OF_SVCS office 
parameter. The NOP MAP level is accessed through the Input/Output 
Device (IOD) MAP level. Refer to Input/Output Devices (IOD) 
Man-Machine Interface Description, 297-1001-513, for more information 
about the IOD MAP level. 


Log reports are generated and OM group registers are pegged as an RO 
passes through the five session states. 


What is the remote operation (RO) service? 
The RO Service handles communication between the DMS applications and 
remote systems by using an RO. An RO is a task requested by one 
processor but performed by another processor. 


The RO Service resides on the top two layers (layers six and seven) of NOP. 
Layer six, the Presentation Layer, is responsible for encoding and decoding 
the data packets into or from the X.409 syntax. Layer seven, the 
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Application Layer, is responsible for the RO X.410 Message Handling 
System (MHS). 


The RO Service uses UP and DOWN tasks (one task pair per SVC) to 
perform its functions. An UP task processes information from an NOS 
product to a DMS application. A DOWN task processes information from a 
DMS application to an NOS product. The following are the four functions 
the RO Service performs: 


e RO buffering 
e application interface 
e interface to RO encode/decode uilities 


e ROs service/X.25 interface 


Remote operation (RO) buffering 
In order to minimize the blocking of data transmitted and received through 
the X.25, the RO Service provides buffering. ROs coming from a remote 
system to an application are received by the RO Service and buffered until 
the application is ready to accept them. Conversely, the RO Service receives 
ROs from the application and holds them until transmission is possible. 


Application interface 
When the RO service receives data from a remote system while using X.25, 
this data must be passed to the application. The RO service provides the 
interface for an application to receive data from the RO service when the 
information is desired. As data is passed to the application from the RO 
service, it is decoded from its X.409 syntax. 


Data generated by an application for transmission to a remote system is sent 
using the RO Service. As data is passed to the RO Service, it is encoded 
into X.409 syntax. 


Interface to remote operation (RO) encode/decode utilities 
The RO Service provides a set of general encoding and decoding utilities for 
the purpose of translating ROs to and from X.409 syntax. These utilities are 
used to build application specific RO encoding and decoding procedures. 


Remote operation (RO) service/x.25 interface 
For an application to communicate with a remote system, it must interface 
with X.25 protocols. The RO service provides this interface to the 
application. 
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The remote operation (RO) for each network operation protocol 
(NOP) application 
Each of the five applications has a set of ROs. The status of each RO is 
displayed at the NOP MAP level using the QUERY command. Refer to 
Table 5-1 on page 5-8 for a complete list of the ROs. 


Table 5-1xxx 
Remote operations for the five applications 


Application Remote operations 


FT DEMAND SEND START STOP 
TRAN CHANGE LIST TEST TIME 
PTAE CILOGON CILOGOUT DEVICE HT HX 
MAP RT SCROLL TRIGGER 
CALM REQUEST UPDATE 
DCR (DCR has ten ROs, but are not displayed at the NOP MAP 
level.) 
Page 1 of 1 


Additionally, there are five other ROs: LOGON, LOGOUT, REJECT (RJ), 
RETURNERROR (RE), and RETURNRESULT (RR). 


Remote operation (RO) service remote operations (ROs) 
The following are the five RO Service ROs: 
1 LOGON: This RO starts the interface between the RO Service and an 


application over a particular SVC. One SVC is used per session. As of 
BCS23, only the DNC generates a LOGON RO. 


2 LOGOUT: This RO can be generated internally within the RO Service 
if a failure occurs. Applications from either the DMS or the DNC 
generate a LOGOUT RO. The LOGOUT RO ends the interface set up 
by the LOGON RO. 


3 REJECT: This RO is generated when an incoming RO is rejected by the 
RO Service. 


4 RETURNERROR: This RO is generated when the RO service cannot 
perform actions on an RO it has received. 


5 RETURNRESULT: This RO is generated when the RO service 
performs an action on an RO it has received. 
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File transfer (FT) remote operation (RO) 
The following are the four types of FT RO: 


1 


DEMAND: This RO is generated from the NOS to the DMS when the 
RETRIEVE FILE soft-function (S/F) key is pressed at the NOS 
terminal. This RO requests that one file or a range of files be transferred 
to a DNC. The selection of the files is done at the NOS terminal. Only 
unprocessed files contained in Table DIRPHOLD can be sent from the 
DMS. 


START: This RO is generated from the NOS to the DMS when the 
START COLLECT S/F key is pressed at the NOS terminal. This RO 
requests that a continuous flow of data be transferred for the given 
stream (AMA, ATT, KT, OM, or SMDR) of data selected at the NOS 
terminal. The flow of data is not stopped unless a STOP RO is sent or 
an exception condition occurs. Active files are sent from the DMS. If 
the need arises, unprocessed files can also be sent. 

SEND: This RO is generated from the DMS to the NOS. This RO 
requests the NOS to accept a block of data. This block of data is the 
result of either a DEMAND or START RO sent to the DMS. 

STOP: This RO is generated from the NOS to the DMS when the STOP 


S/F key is pressed at the NOS terminal. This RO stops the transmission 
of the files selected by the DEMAND or START ROs. 


Transaction (TRAN) remote operation (RO) 
The following are the four types of TRAN ROs: 


1 


CHANGE: This RO is automatically generated from the NOS to the 
DMS when the DNC receives the files requested by a START or 
DEMAND RO. This RO changes the state of the files from unprocessed 
to processed. 

LIST: This RO is generated from the NOS to the DMS when the LIST 
FILES S/F key is pressed at the NOS terminal. This RO lists the DIRP 
files that meet certain criteria selected at the NOS terminal. 

TEST: This RO is automatically generated from the NOS to the DMS 
when the DNC software at the NOS verifies that the DMS session is 
logged on. This RO is sent prior to sending any other ROs. 

TIME: This RO is automatically generated from the NOS to the DMS 
requesting an update to the internal NOS clock. 
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Passthru application entity (PTAE) remote operation (RO) 
The following are the nine types of PTAE ROs: 


1 


CILOGON: This RO is generated from the NOS to the DMS when the 
Command Interpreter (CI) level of the NOS terminal is entered. This 
RO starts a session with the DMS. This RO is generated when the 
LOGON S/F key is pressed at the NOS terminal. 


CILOGOUT: This RO is generated from the NOS to the DMS when the 
CI level of the NOS terminal is exited. This RO terminates a session 
with the DMS. This RO is generated when the EXIT S/F key is pressed 
at the NOS terminal. 


DEVICE: This RO is generated from the NOS to the DMS when the 
CONNECT DEVICE S/F key is pressed at the NOS terminal or 
automatically during a CI logon. This RO requests that a new device be 
assigned for the current CMAP (PTAE) session and be accepted as valid. 
The DMS either validates the new device or rejects the new device by 
sending out an error report in the form of a log report. 

HT: This RO is generated from the NOS to the DMS when the HT S/F 
key is pressed at the NOS terminal. This RO requests that the DMS halt 
the output from the currently executing CI command. 

HX: This RO is generated from the NOS to the DMS when the BREAK 
S/F key is pressed at the NOS terminal. This RO restarts the current CI 
session. Any commands currently being executed are aborted. 

MAP: This RO is generated from the NOS to the DMS when an update 
to the NOS terminal display is requested. 

RT: This RO is generated from the NOS to the DMS when the RT S/F 
key is pressed at the NOS terminal. This RO requests that the DMS 
resume the output from the currently executing CI command. 

SCROLL: This RO is generated from the NOS to the DMS when either 
DMS has more scroll data to send or “more” has been entered from the 
CI MAP level. This RO requests the command to display more scroll 
data. 

TRIGGER: This RO is automatically generated from the DMS to the 
NOS when the state of a session has changed. 


Centralized alarms (CALM) remote operation (RO) 
The following are the two types of CALM RO: 


1 


REQUEST: This RO is automatically generated from the NOS to the 
DMS when a CI session begins requesting the current alarm status of all 
nine maintenance subsystems. The DMS supplies the statuses. 
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2 UPDATE: This RO is automatically generated from the DMS to the 
NOS when an alarm status change is detected during the scan of the 
alarm statuses. The scan is done by the DMS every four seconds. If 
there are no changes to the alarm statuses, this RO is not sent. 


Dynamically controlled routing (DCR) remote operation (RO) 
There are currently ten ROs that control DCR actions. They are not 
displayed at the NOP MAP level. 


How are remote operations (ROs) generated? 
Most of the ROs from the DMS are generated automatically and are in 
response to an RO previously sent from the NOS product; however, there 
are exceptions. The DMS can send INVOKE ROs to the DNC without 
being asked to send an RO. For example, the file transfer SEND RO is sent 
by the DMS whenever there is a block in the data available to send. 


An RO from an NOS product, which resides on a DNC, is generated at the 
NOS terminal by pressing a specific S/F key. Also, it is possible for the 
internal state of the NOS product to send an RO. For example, depending 
on the data stream requested, if the DEMAND S/F key is pressed, a LIST 
RO is sent prior to the DEMAND RO. 


Sending a remote operation (RO) to a network operating system (NOS) 
product 
The following describes what occurs when an RO is sent from a DMS to an 
NOS product and a DOWN task is implemented. 
1 An RO is generated from a DMS application, usually in response to a 
previously sent RO by an NOS product. 


An RO is received from a DMS application by the RO Service. 


3 After the RO is received from the DMS application, the RO Service 
must determine if it can encode the RO. If the RO can be encoded, the 
RO is encoded and sent to the NOS product. 

If the RO cannot be encoded, the ROAPOG register is pegged, log report 
RO103 is generated, and the application is informed that the data was 
not sent. 


Receiving a remote operation (RO) from a network operating system 
(NOS) product 
The following occurs when an RO is received at the DMS from an NOS 
product and an UP task is implemented. 


1 Following are the steps that occur for ROs in general. 
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a. When an RO is received from an NOS Product by the RO Service 
and can be received, the ROMLOGA register is pegged and log 
report RO101 is generated. 


If the RO cannot be received, the ROMFLOG register is pegged, log 
report RO101 is generated, and a CLEANUP is performed on the RO 
buffers. Processing of this RO stops. 


b. After an RO is received, the RO Service must determine if it can 
decode the RO. If the RO can be decoded, it notifies the application. 
When the application is ready to receive the RO, the RO is decoded 
and passed to the application. 


If the RO cannot be decoded, the incoming RO is rejected by the RO 
Service, the ROAPIC register is pegged, log report RO103 is 
generated, and a REJECT RO is sent back. 


2 The following are the steps for the NOS LOGON RO only which set up 
an RO session. 


a. An SVC is acquired. 


b. A NOS LOGON RO is received from the DNC (or whatever remote 
process with which the DMS is communicating), and the incoming 
RO is decoded. 


c. After decoding the incoming LOGON RO, the application ID of the 
LOGON RO is checked to determine whether it is valid. If the 
application ID is valid, the ROAPLOGA register is pegged. 


If the application ID is not valid, the ROMFLOG register is pegged, 
log report RO101 is generated, and a RETURNRESULT RO is sent 
back to the NOS product. The NOS product can send another logon 
RO or terminate the SVC link. 


d. After validating the application ID, a check is made to see if an 
application session is free. If a session is free, RO buffers are 
allocated for the data. The application is notified that a session is 
required. 


If a session is not free, the ROAPFLOG register is pegged, log report 
RO101 is generated, and a RETURNERROR RO is sent back to the 
NOS product. The NOS product can send another logon RO or 
terminate the SVC link. 


e. After allocating buffers, internal flags are set. If the flags can be set, 
the application session is created. 
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If the flags cannot be set, the ROMFLOG and ROAPFLOG registers 
are pegged, log report RO101 is generated, and a RETURNERROR 
RO is sent back to the NOS product. The NOS product can send 
another logon RO or terminate the SVC link. 


f. Once the flags are set, the application is notified that initialization is 
needed. If the session has initialized correctly, a RETURNRESULT 
RO is sent to confirm the success of the operation to the NOS 
product. 


If the session did not initialize correctly, the ROAPFLOG register is 

pegged, log report RO101 is generated, and a RETURNERROR RO 

is sent back to the NOS product. The NOS product can send another 
logon RO or terminate the SVC link. 


The following are the limitations imposed by NOP. 


There can only be as many sessions (SVCs) assigned to the DMS-100 as 
there are datafilled in the NOS_QUANTITY_OF_SVCS office 
parameter. 


The maximum number of sessions (SVCs) is 15. 


Refer to Common Customer Data Schema, 297-1001-451, for the data 
schema limitations of Tables MPC, X25LINK, DPACDEV, and 
XFERSSYS. 

When changing the NOS_QUANTITY_OF_SVCS office parameter, a 
restart (warm, cold, or reload) must be done to activate the change. 


The following are the restrictions imposed by NOP. 


Only one data stream per SVC may be accessed at one time. 


2 Different SVC cannot access the same data stream. 
3 The NOP can only use one IOD at a time; that is, if NOP is set to use an 


MPC, all applications using NOP to communicate with a remote system 
must use an MPC. For example, the PTAE application cannot use a 
DPC while the FT application is using an MPC. The NOP can only use 
the I/O feature packages loaded into the switch and datafilled in Table 
GDLADEV. 


To change which IOD NOP uses, all tuples in NOPADDR must be 
deleted before changing Table GDLADEV. 
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AMA 

Automatic message accounting 
AMAT 

Automatic message accounting transmitter 
ATT 


Automatic trunk testing 


Automatic message accounting (AMA) 
AMA is an automatic recording system that documents all the necessary 
billing data of subscriber-dialed long distance calls. 


Automatic message accounting transmitter (AMAT) 
AMAT is a subsystem of the automatic message accounting teleprocessing 
system that, on request, transmits automatic message accounting data to the 
collector in the central office. 


Automatic trunk testing (ATT) 
ATT is a set of hardware and software entities that provide automatic testing 
for outgoing trunks and the outgoing portions of two-way trunks. 


Batch change supplement (BCS) 
BCS is a DMS-100 Family software release. 


BCS 


Batch change supplement 


Bell-Northern Research (BNR) 
BNR is a part of the tri-corporate structure consisting of Bell Canada, 
Northern Telecom, and Bell-Northern Research. 


BF 
Fixed block (format) 
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BNM 
Business Network Management 


BNR 
Bell-Northern Research 


Business Network Management (BNM) 
BNM is a product that is an application of Northern Teelcom;s Dynamic 
Network Control products that gives customers direct access to call detail 
station administration, and performance information from one or more 
Meridian Digital Centrex nodes in their telecommunications network 


Central processing unit (CPU) 
CPU is a hardware entity, located in the central control complex frame, that 
contains the central data processor for the DMS-100 Family system. 


CALM 


Centralized alarm 


Centralized alarm (CALM) 
CALM is an application that sends alarms from a DMS to an NOS product 
user at a terminal. There can be a maximum of two CALM sessions at one 
time, that is, two CALM sessions can be sent at one give time to a particular 
NOS product. 


Centralized maintenance and administration position (CMAP) 


Centralized operations administration and maintenance (COAM) 
COAM is an application on DNC-500 hardware providing centralized 
operation, administration, and maintenance for DMS-100 Family products. 
One application is for the DMS-100 host and up to eight large business 
remotes in a DMS-100 switching cluster. 


Cl 

Command interpreter 
CMAP 

Centralized maintenance and administration position 
COAM 


Centralized operations administration and maintenance 


297-1001-524 Standard 09.01 October 1991 


List of terms 6-3 


Command interpreter (Cl) 
Cl] is a support operating system component that functions as the main 
interface between machine and user. Its principal roles include 


CPU 


reading lines entered by a terminal user 

breaking each line into recognizable units 

analyzing the units 

recognizing command item-numbers on the input lines 


invoking these commands 


Central processing unit 


CRC 


Cyclical redundancy check 


Cyclical redundancy check (CRC) 


Data packet collector (DPA) 
DPA is an input/output device used for data communications with the 
DMS-100. 


DCR 


Dynamically controlled routing 


Device independent recording package (DIRP) 
DIRP is software that automatically directs data from the various 
administrative and maintenance facilities to the appropriate recording 
devices. 


Digital Multiplex System (DMS) 
DMS is a central office switching system in which all external signals are 
converted to digital data and stored in assigned time slots. Switching is 
performed by reassigning the original time slots. 


DIRP 


Device independent recording package 


DMS 


Digital multiplex system 


DNC 


Dynamic network management 
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DPC 
Data packet collector 


Dynamic network controller (DNC) 
DNC is a family of applications that is part of Northern Telecom’s dynamic 
network architecture. These applications generally provide an enhanced 
level of network control and allow operating companies to develop their 
service management and administration system independently of the 
evolution of their network equipment. 


Dynamically-controlled routing (DCR) 
DRC is a feature that reserves idle trunks in trunk groups to provide routes 
for overflow traffic. The trunks are separated by one or more links from an 
originating toll switch. 


EIA 


Electronic Industries Association 


Electronic Industries Association (EIA) 
EIA is an American organization made up of manufacturers of a wide 
variety of electronic products including telecommunications equipment. 
The EIA is active setting industry standards. 


EXT 
External 


External (EXT) 


File transfer (FT) 
FT is an application that provides the DMS with the capability to transfer 
operating company and customer data stored in the Device Independent 
Recording Package subsystem over a communication link. 


FT 


File transfer 


IDO 


International standards organization 


Input/output controller (IOC) 
IOC is an equipment shelf that provides an interface between up to 
thirty-six input/output devices and the central message controller. The IOC 
contains a peripheral processor that independently performs local tasks, thus 
relieving the load on the central processing unit. 
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Input/output device (IOD) 
IOD is a device that interprets input and formats output for human users or 
remote computers. 


International Standards Organization (ISO) 
ISO is the organization responsible for creating a seven-layer protocol 
model for a data communications network. 


IOC 


Input/output controller 


IOD 
Input/output device 


Killer trunk (KI) 


KT 
Killer trunk 


Large business remotes (LBR) 
LBR is a DMS-100 that is configured to serve as a remote switching unit. 


LBR 


Large business remotes 


Magnetic tape drive (MTD) 
In DMS, an MTD is a device used to record DMS-100 Family data. An 
MTD may be mounted on either a magnetic tape center frame or an 
input/output equipment frame. 


Maintenance and administration position (MAP) 
A MAP is a group of components that provide a man-machine interface 
between operating company personnel and the DMS-100 Family systems. 
A MAP consists of a visual display unit and keyboard, a voice 
communications module, test facilities, and MAP furniture. MAP is a 
trademark of Northern Telecom. 


MAP 


Maintenance and administration position 


MDC 
Meridian Digital Centrex 
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Meridian Digital Centrex (MDC) 
MDC is a special DMS business services package that utilizes the 
data-handling capabilities of DMS-100 Family offices and provides a 
centralized telephone exchange service. It is formally known as Integrated 
Business Network (IBN). 


Message handling system (MHS) 


MHS 

Message handling system 
MPC 

Multi-protocol controller 
MTD 


Magnetic tape drive 


Multi-protocol controller (MPC) 
MPC is a general-purpose data communications card that allows data 
communications between a DMS-100 Family switch and an external 
computer (for example, between a central office billing computer and a 
DMS-100 Family switch). The MPC card resides on the input/output 
controller shelf. MPC card protocol software is downloaded from the 
DMS-100 central processing unit and then supports software routines for 
data packet network communication. 


Network operation protocol (NOP) 
The NOP protocol provides an interface between a DMS-100 Family switch 
and its remote systems. 


Network operating system (NOS) 
NOS is a facility providing the DMS-100 with the capability of transferring 
data over communication links to a telephone network operating system. 


NOP 


Network operation protocol 


Northern Telecom (NT) 
NT is part of the tri-corporate structure consisting of Bell-Northern 
Research, Bell Canada, and Norther Telecom. 


NOS 


Network operating system 
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NT 


Northern Telecom 


OM 


Operational measurements 


Operational measurements (OM) 
OMs are the hardware and software resources of the DMS-100 Family 
systems that control the collection and display of measurements taken on an 
operating system. OMs organize the measurement data and manage its 
transfer to displays and records on which maintenance, traffic, accounting, 
and provisioning decisions are based. 


Passthru application entity (PTAE) 
PTAE is an application also known as Centralized MAP. It allows network 
operation system user access to the DMS MAP from a remote system. 


Passthru DMS access (PTDA) 


PEC 


Product engineering code 


Product engineering code (PEC) 
The PEC is an eight-character code that provides a unique identification for 
each marketable product manufactured by Northern Telecom. 


PTAE 

Passthru application entity 
PTDA 

Passthru DMS access 
RAO 


Revenue accounting office 


Remote data polling system (XFER) 
XFER is a system that permits an operating company to transfer information 
concerning the operation of a DMS-100 Family office to its data processing 
center. 


Remote operation (RO) 
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Revenue accounting office (RAO) 
RAO is a data center that produces subscriber bills from host office 
automatic message accounting data. 


RO 

Remote operation 
SDS 

Station detail server 
S/F 

soft function 
SLM 

System load module 
SMDR 


Station message detail recording 


Soft function (S/F) 


Software operating system (SOS) 


SOS 


Software operating system 


Station detail server (SDS) 
SDS is a member of the DNC-500 BNM family. The SDS provides station 
message detail recording from a DMS-100 to an end-user premises. 


Station message detail recording (SMDR) 
In Meridian Digital Centrex, SMDR is a system that provides recording 
facilities for the details of billable and nonbillable calls for each MDC 
customer group. 


SVC 


Switched virtual circuit 


Switched virtual circuit (SVC) 
SVC is a logical, end-to-end connection for data communication made 
through a packet data network. An SVC is established dynamically. 


TRAN 


Transaction 
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Transaction (TRAN) 


TRAN is an application that sends supervisory information. 


Variable-blocked (VB) 


In DMS, VB is a magnetic tape format for blocks of variable-length data 
records. In a VB format, the total length of one or more records in a block 
may not exceed the maximum block. See also variable-blocked-spanned. 


Variable-blocked-spanned (VBS) 


VB 


VDU 


In DMS, VBS is a magnetic tape format for blocks of variable-length data 
records where the total length of one or more records may exceed the 
maximum block size. In a VBS format, the overflow of the last record is 
spanned into the beginning of the next block. See also variable-blocked. 


Variable block (format) 


Visual display unit 


Visual display unit (VDU) 


XFER 


VDU is an electronic output device that presents data to a terminal user in 
the form of a television picture. In DMS, the VDU is one of the components 
of the maintenance and administration position, and, along with a keyboard, 
provides the main man-machine interface in the DMS-100 Family of 
systems. 


Remote data polling system 
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DMS-100 Family 


Remote Data Polling System 
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